【レポート】ネットワークパフォーマンス : 全てのパケットを精査する #reinvent #NET401

【レポート】ネットワークパフォーマンス : 全てのパケットを精査する #reinvent #NET401

Clock Icon2017.12.01

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

re:Intent2017のセッション「NET401 - Network Performance: Making Every Packet Count」のレポートです。

スピーカーはMike Furr(Principal Software Engineer, Amazon)です。

本セッションはネットワーク(主にTCP)のボトルネックを解明し、ベストパフォーマンスを発揮するための手法を解説します。

  • TCPは優れた仕組みを持つ
    • SSH、HTTP、*SQL、SMTPの下のレイヤーで動作
    • ストリーミングデリバリ、フロー制御
  • TCPのコネクション
    • 3Wayハンドシェイク
    • 送信データの制限 送信側、受信側それぞれの制限がある
    • 送信遅延積
    • 受信ウィンドウ 受信ウィンドウで受信可能なデータを通知
      受信ウィンドウサイズの調節。Linuxカーネルパラメータの例
    • 輻輳ウィンドウ ウィンドウは輻輳アルゴリズムによって管理され、パケットロス、レイテンシ、帯域幅が関係する
    • 初期の輻輳ウィンドウは3
    • 16に増やす例(Linux iproute2ではinitcwnd)
    • パケットロスによるTCPスループットへの影響
    • TCPの再送でパケットロスの様子がわかるnetstat -sユーティリティーのretransmit
    • ssユーティリティでネットワークソケットの状況を確認 Send-Q、cubic、rto、cwnd、retrans辺りをチェック
    • tcpretransで再送をリアルタイムに監視 作者のBrendan GreggはNetflixのエンジニア
  • 輻輳アルゴリズム
    • Linuxの輻輳制御アルゴリズムは様々。ネットワーク環境に適したアルゴリズムを選択
    • 輻輳アルゴリズムのチューニングカーネルパラメータでアルゴリズムを確認、輻輳アルゴリズム自体はカーネルモジュールで提供されるので、modprobeでロードする
    • BBR
  • 再送タイマー 短すぎても、長すぎても良くない
  • 再送タイマー(rto_min)を短くする例
  • キューのアクティブな管理 ここではキューをfq_codelに変更
  • MTU MTUを大きくすることでオーバーヘッドの小さい、効率の良い通信に
  • EC2拡張ネットワーキング
    • 従来の仮想NICはハイパーバイザーの処理がオーバーヘッドになる
    • Intel 82559のSR-IOVで仮想化レイヤーをバイパス
    • ENAでさらに性能アップ

やってみた

  • テスト要件
  • 1つ目 : HTTPSで0.5%のロス
    • テスト要件  - p90とp99ラインで2本のグラフ。0.5%lossでどうなる?  - デフォルトのCubicと比較しillinoisでは? p90が75%Fasterに
    • BBRはさらに良い
    • BBRのロスなしと比較
    • そもそも、CubicとBBRの両方ロスなしも比較
  • 2つ目 : 再送タイムアウトの調整
    • p50とp99.99の比較 Web APIなどでは99.99%も求められることがあるのでは
    • RTOを50にしたら改善した
  • 3つ目 : 大量アクセス ゴールはレイテンシの最小化

    • こちらは、ウィンドウ数を増やしてスループットを改善
  • まとめ

所感

チューニング項目自体は一般的なTCPのチューニングがAWS環境でも有効なことがわかりますね。仮説と検証を繰り返す地道なところですが、AWSのネットワークリソースをより効率良く利用するために大事なポイントだと思います。皆さんのネットワークパフォーマンスの改善に役立つと嬉しいです。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.